Automobile Controller, Software Generation Method and Software Generation System Thereof

ABSTRACT

In a processing description part  180 , macros are used to describe processing in layers L 1  and L 2  with labels in each layer. A hierarchical configuration description part  191  defines the relation of connection between layers with macros of labels in each layer. An identifier expanding part  192  performs macro expansion. When these parts and a compiler  914  are used, control software that includes only a single expanded layer is obtained. 
     The software obtained is stored in, for example, a ROM  205  or the like in a control unit  200  in an automobile controller. 
     Accordingly, the processing description part  180  can be layered in an easy to understand manner, and thus person-hours for software modification can be localized when hardware or the control method is modified. Furthermore, execution speed of applications can be increased and the necessary capacity of the storage device can be reduced.

TECHNICAL FIELD

The present invention relates to an automobile controller, as well as amethod of and a system for generating software for a microprocessorconstituting part of the automobile controller.

BACKGROUND ART

Microprocessors including a CPU, a ROM, a RAM, an input/output signalprocessor, and other components have been used as controllers intendedfor automobile engine control and the like. Software installed in thistype of microprocessor comprises application programs that performcontrol processing and device drivers that perform input and outputoperations so that a desired control operation is achieved. Whenhardware used is modified, the device drivers for input and outputoperations are easily affected and a large number of person-hoursinvolved in the modification become problematic.

Modifications of hardware are broadly classified into two types;modifications of sensors and actuators that are subject to control andmodifications of the microprocessor that performs control. When asensor, an actuator, or other hardware subject to control is modified,software is developed so that a target control operation is achieved,with reference to a hardware manual or another document in which itscharacteristics and specifications are described. When themicroprocessor is modified, many person-hours are needed to extractportions to be modified, determine new specifications, perform amodification, and verify the modification with reference to a manual inwhich the specifications of the microprocessor are described.

To reduce person-hours required for a software modification involved ina hardware modification, UNIX (a registered trademark), which is ageneral-purpose operating system (OS) intended for information systems,is available, as disclosed in Non-patent Document 1. In UNIX, interfacesto the hardware subject to control are classified into three standardinterfaces, which are block-type interfaces, message channel-typeinterfaces, and character-type interfaces. All input/output programseach use any one of the three types of virtual interfaces. Accordingly,software is structured with three layers, which are applications,virtual drivers, and actual driver programs, enabling applicationprograms to be developed without having to worry about the modificationof the hardware.

In Patent Document 1, a device driver is divided into three layers sothat a modification of a program responsive to a modification of adevice can be localized.

In Non-patent Document 2, a device driver is created as a high-orderdriver and a low-order driver; the high-order driver uses an interfacefor the low-order driver to perform processing, eliminating effects bymodifications of the microprocessor and other hardware.

In a known technique to speed up processing performed through aninterface, macros are used for expansion. The calling of the processingperformed through an interface is speeded up by macro substitution, asdisclosed in Patent Document 2.

Non-patent Document 1: S. J. Leffler, et al., translated by AkiraNakamura, et al., The Design and Implementation of the 4.3 BSD UNIXOperating System, Maruzen Co., Ltd. (1991)

Patent Document 1: Japanese Patent Laid-open No. 2000-97102

Non-patent Document 2: μITRON4.0 Specification Study Group, DeviceDriver Design Guides, μITRON4.0 Specification Study Group (1999)

Patent Document 2: Japanese Patent Laid-open No. 2002-287981

DISCLOSURE OF INVENTION Problems to be Solved by the Invention

However, in processing performed by general preprocessors, which processmacros in C and other languages, character strings are replaced insuccession, so they cannot process processing comprising a plurality oflayers at high speed. Accordingly, the conventional technologies cannotsuppress a processing overhead generated each time processing passesthrough a layer. A device driver comprising, for example, three layerscalls the three layers to perform one type of input/output processing,resulting in a long program execution time and a large program size. Toachieve real-time control suitable for automobiles and the like,processing for calculation, input/output processing, and otherprocessing must be performed individually at an optimum timing; a delayof even several microseconds is not often allowed. When layered softwareis implemented in an ordinary manner, functions calls and system callsare generated between each two layers and a non-negligible delay iscaused. When these calls are translated into machine instructions by acompiler or the like in a microprocessor, the calling processingresulting from each call comprises one to eight instructions, taking anexecution time of several microseconds to tens of microseconds. Datacorresponding to connection between layers needs to be stored in astorage means such as a ROM, RAM, or disk, increasing a necessary memorycapacity.

For automobile engine controllers and other systems mounted, there arerequests for reducing capacities of ROMs and RAMs, which directly affectcosts. Since control of these systems is performed in real time, thereare also difficult requests for response speeds. These overheads becomea significant problem in practical use.

An object of the present invention is to reduce person-hours taken forsoftware modification involved in modification of hardware or a controlmethod so as to increase application execution speeds and reducenecessary storage unit capacities.

Means for Solving the Problems

The present invention, in one aspect, generates a first processingdescription part divided into a plurality of layers, an identifierexpanding part for expanding an identifier used in the first processingdescription part, and a hierarchical configuration description part inwhich to describe the hierarchical configuration of the first processingdescription part, and also generates a second processing descriptionpart comprising a single layer, which results from an expansion of thehierarchical configuration of the first processing description part intoa single layer in accordance with data described in the hierarchicalconfiguration description part and the identifier expanding part.

In a preferred embodiment of the present invention, desired executablesoftware can be obtained in a second processing description part, whichis expanded into a single layer by using a first processing descriptionpart, a hierarchical configuration description part, an identifierexpanding part, a preprocessor, and a compiler; in the first processingdescription part, processing for each layer is described by using macrosrepresenting labels defined for the each layer; in the hierarchicalconfiguration description part, connection relationships among layersare defined by using macros representing the labels for each layer; theidentifier expanding part performing macro expansion according to thehierarchical configuration description part.

In a software generating system for an automobile controller that uses amicroprocessor to control an automobile, a software generating system inanother aspect of the present invention comprises a means for generatinga first processing description part divided into a plurality of layers,a means for generating an identifier expanding part for expanding anidentifier used in the first processing description part, a means forgenerating a hierarchical configuration description part in which todescribe the hierarchical configuration of the first processingdescription part, and a means for generating a second processingdescription part comprising a single layer, which results from anexpansion of the hierarchical configuration of the first processingdescription part in accordance with data described in the hierarchicalconfiguration description part and the identifier expanding part.

In the preferred embodiment of the present invention, there are provideda preprocessor for generating the second processing description part, acompiler for translating the second processing description part into anobject file, and a linker for generating control software to be writtenin a storage unit of the automobile controller by linking the objectfile to an application object file.

EFFECTS OF THE INVENTION

According to the present invention, software designed as a plurality ofhierarchical layers is compiled into software that includes only asingle layer and thereby does not suffer an overhead between layers.

Other objects and features of the present invention will be clarified inthe description of embodiments described below.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows the structures of a device driver developed according to anembodiment of the present invention as well as applications andhardware.

FIG. 2 shows the structure of an automobile engine control system in theembodiment of the present invention.

FIGS. 3A to 3D illustrate a concrete example of the upper layer (L1) inthe processing description part shown in FIG. 1 in detail.

FIGS. 4A to 4D illustrate a concrete example of the lower layer (L2) inthe processing description part shown in FIG. 1 in detail.

FIGS. 5A and 5B show the hierarchical configuration description part inthe device driver shown in FIG. 1 in detail.

FIG. 6 shows the identifier expanding part in the device driver shown inFIG. 1 in detail.

FIG. 7 shows a development procedure in an embodiment of the presentinvention.

FIGS. 8A to 8D illustrate examples of source code from which theoverhead between layers is eliminated according to an embodiment of thepresent invention.

FIG. 9 shows a development environment and a development procedure toimplement a device driver generation method in an embodiment of thepresent invention.

FIG. 10 shows an exemplary input/output terminal list in an embodimentof the present invention.

LEGENDS

100 . . . application program, 101 . . . injection control application,102 . . . ignition control application, 110 . . . operating system, 120. . . device driver, 121 . . . intake air amount calculation (IAA), 122. . . intake air temperature calculation (IAT), 130, 201 microprocessor(CPU), 131 to 133, 203 . . . input/output port, 140 . . . applicationprogram interface (API), 150 . . . hardware interface (HWI), 160 . . .upper layer (L1), 170 . . . lower layer (L2), 171 . . . first-orderfilter analog input (FAI), 172 . . . Vcc correction analog input (VAI),180 identifier expanding part, 191 . . . hierarchical configurationdescription part, 192 . . . identifier expanding part, 200 . . . controlunit, 220 . . . sensor actuator, 71 . . . device driver program sourcecode, 72 build, 73 . . . device driver object file, 902 . . . devicedriver repository, 905 . . . input/output terminal list, 906 . . .hierarchical configuration generator, 911 . . . preprocessor, 913 . . .expanded processing description part, 914 . . . compiler, 916 . . .device driver object file, 917 . . . application source code, 918 . . .application object file, 919 . . . linker, 921 . . . control software

BEST MODES FOR CARRYING OUT THE INVENTION

Embodiments of the present invention will be described below withreference to the drawings.

FIG. 1 shows the structures of a device driver developed according to anembodiment of the present invention as well as applications andhardware. The drawing shows an example of a device driver 120 thataccepts inputs obtained from sensors through input/output ports 131 to133 of a microprocessor 130 and uses the inputs to calculate an amountof intake air and an intake air temperature. An overview of anautomobile engine control system that performs control will be firstgiven before the device driver 120 is described in detail.

FIG. 2 shows the structure of an automobile engine control system in anembodiment of the present invention. The control unit 200 includes a CPU201, an interrupt controller 202, a time pulse controller 203, an ADconverter 204, a ROM 205, and a RAM 206. These components areinterconnected through a bus 207 and make external accesses through aninput/output port 208. The components 202 to 208 may be included in onedevice, or included in different devices and interconnected. Referencenumeral 210 indicates a power supply for the control unit 200.

A sensor actuator 220 to be controlled is connected to the control unit200 through the input/output port 208. The sensor actuator 220 comprisesan air flow sensor 221, an electronically controlled throttle 222, aninjector 223, an ignition plug 224, an air-to-fuel ratio sensor 225 suchas a lean air fuel (LAF) sensor, and a crank angle sensor 226. Thecontrol unit 200 controls these components. Specifically, to achievecontrol, the CPU 201 and other components in the control unit 200 writeto and read from registers in the input/output port 208. Software inwhich a control method is described is stored in the ROM 205 and RAM 206in the control unit 200.

This embodiment relates to a method of generating this type of softwarein such a way that the software can be modified easily even when, forexample, hardware is modified and that applications are executed fastand thus the capacity of memory can be reduced.

The configuration of software executed by the control unit 200 in FIG. 2will be described with reference again to FIG. 1. Software is broadlyclassified into three categories, which are an application program 100,operating system (OS) 110, and device driver 120. The applicationprogram 100 sends and receives information and processing to and fromthe OS 110 and device driver 120 through the application programinterface (API) 140. When the API 140 is standardized independently ofthe hardware connected, even if the hardware is modified, effects on theapplication program 100 can be avoided. The OS 110 and device driver 120control the application program through a hardware interface (HWI) 150of the input/output ports 131 to 133 etc. of the microprocessor 130.

The exemplary device driver 120 shown in the drawing performs an intakeair amount calculation 121 and an intake air temperature calculation 122according to inputs obtained from the sensors through the input/outputports 131 to 133 of the microprocessor 130. The device driver 120accepts requests from an injection control application 101, an ignitioncontrol application 102, and the like in the application program 100through the API 140. The CPU 130 is responsible for control of this; itperforms target control by reading from and writing to the analoginput/output ports 131 to 133 and the like through the HWI 150.

The device driver 120 is developed in layers by breaking down it into,for example, the upper layer (L1) 160 and lower layer (L2) 170 so thatpoints to modify are localized. There is no restriction on the number oflayers; the device driver 120 can be implemented by an appropriatenumber of layers according to what is responsible for control and howlarge the software is. The description below assumes a case in which twolayers are used.

The upper layer (L1) 160 in the processing description part 180 includesthe intake air amount calculation 121, intake air temperaturecalculation 122, and other modules that require input values needed bythe application program 100. In the lower layer (L2) 170 includingmodules that receive input values and perform general input processing,processing to be performed is described. In the drawing, a first-orderfilter analog input (FAI) 171 and Vcc correction analogy input (VAI) 172are indicated. A concrete configuration between layers that indicateswhich upper layer uses which lower layer is described in thehierarchical configuration description part 191. The identifierexpanding part 192 is used to associate the hierarchical configurationdefined in the hierarchical configuration description part 191 with theprocessing description part 180 to obtain desired output.

FIGS. 3A to 3D and FIGS. 4A to 4D illustrate concrete examples of theupper layer (L1) 160 and lower layer (L2) 170 in the processingdescription part 180, respectively, in detail. These examples will bedescribed below.

FIGS. 3A to 3D illustrate the intake air amount calculation (IAA) 121 inthe upper layer (L1) 160 shown in FIG. 1 in detail.

FIG. 3A outlines processing. As shown in the drawing, the intake airamount calculation module has intake air amount update processing namedprocessing name 1, intake air amount acquisition processing namedprocessing name 2, and Vcc correction analog input provided as inputprocessing necessary for this calculation. FIG. 3B is a flowchart thatschematically shows the above intake air amount update processing. FIG.3C is also a flowchart that schematically shows the above intake airamount acquisition processing. FIG. 3D is an example of program codethat implements FIGS. 3A, 3B, and 3C.

In the intake air amount calculation processing in FIG. 3B, the Vcccorrection analog input (VAI) in the lower layer L2 updates an inputvalue in step 301, and the updated value is then obtained in step 302. Amap for correcting air flow sensor characteristics is used to performcorrection according to the obtained value in step 303. A value obtainedby the above correction is stored in a buffer in step 304.

In the intake air amount acquisition processing in FIG. 3C, the value inthe above buffer is returned in step 305.

FIG. 3D shows an example of a program source in which the aboveprocessing is described with macros in C. In the macro description, acall of another module is coded as Ln_Proc(_Ln(ID)), and data referenceis coded as Ls_(ID). Ln is the layer name of a module to be called, Procis the name of processing to be called, ID is the name of the callingmodule, and Ls is the layer name of the calling module.

FIG. 4A to 4D illustrate the Vcc correction analog input (VAI) 172,which is an element of the lower layer (L2) 170 shown in FIG. 1, indetail.

FIG. 4A outlines processing. As shown in the drawing, the Vcc correctionanalog input module has Vcc correction analog input value updateprocessing named processing name 1, Vcc correction analog input valueacquisition processing named processing name 2, and input from amicroprocessor port provided as an input type necessary for thisprocessing. FIG. 4B is a flowchart for the Vcc correction analog inputvalue update processing. FIG. 4C is also a flowchart for the Vcccorrection analog input value acquisition processing. FIG. 4D is anexample of source code that implements FIGS. 4A, 4B, and 4C.

In the Vcc correction analog input value update processing in FIG. 4B,Vcc is input from a microprocessor port through the hardware interface(HWI) 150 in step 401. A Vcc correction coefficient is then multipliedto obtain an updated value in step 402. The updated value obtained isstored in a buffer in step 403.

In the Vcc correction analog input value acquisition processing in FIG.4C, the value in the above buffer is returned in step 404.

FIG. 4D shows an example of a program source in which the aboveprocessing is described with macros in C. Macros are described in thesame way as in FIG. 3D.

FIGS. 5A and 5B show the hierarchical configuration description part 191in the device driver 120 shown in FIG. 1 in detail.

FIG. 5A outlines the configuration, indicating that the label names ofprocessing modules are IAT, IAA, VAI, and FAI, and that the label namesof processing modules below these processing modules are FAI, VAI, AN1,and AN2. That is, the low-order module of the intake air temperaturecalculation (IAT) 122 is the first-order filter analog input 171, thelabel of which is FAI; the low-order module of the intake air amountcalculation (IAA) 121 is the Vcc correction analog input 172, the labelof which is VAI; the hardware corresponding to the first-order filteranalog input 171 with the label FAI is the analog input/output port, thelabel of which is AN2; the hardware corresponding to the Vcc correctionanalog input 172 with the label VAI is the analog input/output port, thelabel of which is AN1.

FIG. 5B shows source code of the hierarchical configuration descriptionpart 191 implemented according to the hierarchical configuration in FIG.5A. The source code is described with macros in the form of “#defineID_Ln IDn” or “#define ID _ADDR xxxx”. ID is the identifier (label) ofthe device driver module; IDn is the identifier (label) of anothermodule related to the module; _ADDR is an identifier indicating amicroprocessor port; xxx is a port name.

FIG. 6 shows the identifier expanding part 192 in the device driver 120shown in FIG. 1 in detail. The identifier expanding part is in the formof “#define _Ln(ly) ly # #_Ln” “#define _ADDR(ly) ly# #_ADDR”, or“#define Ln_(ly) Ln_# #ly”. Ln is the name of the upper layer; ADDR isan arbitrary identifier indicating a port of the microprocessor; othersymbols have the same meanings as described above. To expand macrosbetween layers, these identifiers are replaced with the labels of otherlayers by using the identifier linking function “# #” in C.

FIG. 7 shows a development procedure in which the processing descriptionpart, hierarchical configuration description part, and identifierexpanding part described above are used. The hierarchical configurationdescription part 711, identifier expanding part 712, and processingdescription part 713 in the device driver program source code 71generated as described above are passed through the build 72 to obtain adevice driver object file 73. Specifically, when the preprocessor 721and compiler 722 are used for translation into machine code, the devicedriver object file 73 is output. In the device driver object file 73,the processing description part generated as layers is expanded into asingle layer by the preprocessor 721, eliminating the overhead betweenthe layers.

FIGS. 8A to 8D illustrate examples of source code from which theoverhead between layers is eliminated according to an embodiment of thepresent invention. FIG. 8A shows calling source code, and FIG. 8B showscode resulting from the expansion of the source code by the preprocessor721. When the preprocessor 721 performs macro expansion, the inter-layercalling processing in steps 301 and 302 in FIG. 3B and step 401 in FIG.4B is expanded into a single layer. Accordingly, processing to savearguments and stack pointers used to call other layers becomesunnecessary, speeding up the processing and downsizing the code.

FIG. 8C shows machine code in the conventional technique, and FIG. 8Dshows an example in which there is a reduction according to anembodiment of the present invention. Specifically, the machine code formaking a call in step 301 in FIG. 3B is a part 81 enclosed by dashedlines in FIG. 8C. The part 81 can be eliminated for each inter-layercall.

FIG. 9 shows a development environment and a development procedure toimplement a device driver generation method in an embodiment of thepresent invention. An identifier expanding part 192 and processingdescription part 180 in the device driver 120, which has been alreadycreated, are registered in step 901. In step 903, a necessary identifierexpanding part 192 and processing description part 180 are obtained froma device driver repository 902 in which they are stored. An input/outputterminal list 905, which is part of controller specifications 904obtained from hardware designing and describing correspondence betweenmicroprocessor ports and devices, is input. A hierarchical configurationgenerator 906 is then used to obtain a hierarchical configurationdescription part 908 in step 907. The hierarchical configurationdescription part 908, identifier expanding part 909, and processingdescription part 910 thus obtained undergo macro expansion by apreprocessor 911 in step 912. Accordingly, a processing description part913, in which a hierarchical configuration is expanded according to theidentifier expanding part 909 and hierarchical configuration descriptionpart 908, can be obtained from the processing description part 910described by use of layers. The processing description part 913resulting from the expansion has no hierarchical configuration, that is,comprises only a single layer, eliminating the overhead for inter-layerprocessing. Then, a device driver object file 916 is obtained in step915 in which compilation is performed by a compiler 914. In step 920,the device driver object file 916 is linked by a linker 919 to anapplication object file 918, which results from compilation of anapplication source code 917, and control software 921 is then produced.

FIG. 10 shows an example of an input/output terminal list 905. Theinput/output terminal list 905 shows correspondence between hardwaredevices and control unit terminals. When this list is used to make theupper layer (L1) 160 correspond to a hardware device and the lower layerto correspond to hardware ports 131 to 133, FIG. 10 matches FIG. 5A.Accordingly, the hierarchical configuration generator 906 outputs thelist in FIG. 5B. When the hierarchical configuration generator 906 isused, the processing description part 908 can be automatically generatedfrom the input/output terminal list 905 on a computer, therebyincreasing productivity. The hierarchical configuration generator 906,device driver repository 902, and compiler 914 can be implemented by useof a computer having input means, such as a keyboard, mouse, andnetwork, an output means such as a CRT, and a storage means such as ahard disk drive.

INDUSTRIAL APPLICABILITY

An electronic control unit in an engine controller mounted in anautomobile requires high-speed processing and high reliability and isfrequently subject to hardware modifications. When the inventivesoftware generation method and software generation system intended for amicroprocessor is used in such an electronic control unit, the burden ofthe developer can be greatly reduced and a high applicability can beexpected.

1. A software generating method for an automobile controller that uses amicroprocessor to control an automobile, the method comprising the stepsof: generating a first processing description part divided into aplurality of layers; generating an identifier expanding part forexpanding an identifier used in the first processing description part;generating a hierarchical configuration description part in which todescribe the hierarchical configuration of the first processingdescription part; and generating a second processing description partcomprising a single layer, which results from an expansion of thehierarchical configuration of the first processing description part inaccordance with data described in the hierarchical configurationdescription part and the identifier expanding part.
 2. A softwaregenerating method for an automobile controller that uses amicroprocessor to control an automobile, the method comprising the stepsof: generating a first processing description part divided into aplurality of layers; generating an identifier expanding part forexpanding an identifier used in the first processing description part;and generating a second processing description part comprising a singlelayer, which results from an expansion of the hierarchical configurationof the first processing description part in accordance with datadescribed in the identifier expanding part and a hierarchicalconfiguration description part in which the hierarchical configurationof the first processing description part is described.
 3. The softwaregenerating method for an automobile controller according to claim 1,wherein the hierarchical configuration description part includes thenames of output terminals of the microprocessor.
 4. The softwaregenerating method for an automobile controller according to claim 1,wherein the identifier expanding part includes an identifier linkinginstruction in a programming language.
 5. The software generating methodfor an automobile controller according to claim 1, further comprisingthe step of generating the hierarchical configuration description partaccording to an input/output terminal list in which correspondencebetween hardware devices and input/output terminals of a control unitincluding the microprocessor is described.
 6. The software generatingmethod for an automobile controller according to claim 1, wherein thestep of generating the hierarchical configuration description partincludes the step of generating the hierarchical configurationdescription part according to an input/output terminal list described inspecifications for the automobile controller.
 7. The software generatingmethod for an automobile controller according to claim 1, furthercomprising the steps of generating source code of an application programthat is part of software executed in a control unit in the automobilecontroller; converting the source code of the application program intoan object file; converting the second processing description partresulting from the expansion into another object file; and linking theapplication program and the second processing description part, whichhave been converted into the object files, and writing the linked objectfiles in a storage unit in the microprocessor as control software.
 8. Asoftware generating system for an automobile controller that uses amicroprocessor to control an automobile, the system comprising: a meansfor generating a first processing description part divided into aplurality of layers; a means for generating an identifier expanding partfor expanding an identifier used in the first processing descriptionpart; a means for generating a hierarchical configuration descriptionpart in which to describe the hierarchical configuration of the firstprocessing description part; and a means for generating a secondprocessing description part comprising a single layer, which resultsfrom an expansion of the hierarchical configuration of the firstprocessing description part in accordance with data described in thehierarchical configuration description part and the identifier expandingpart.
 9. A software generating system for an automobile controller thatuses a microprocessor to control an automobile, the system comprising apreprocessor for generating an identifier expanding part for expandingan identifier used in a first processing description part divided into aplurality of layers, a hierarchical configuration description part inwhich the hierarchical configuration of the first processing descriptionpart is described, and a second processing description part comprising asingle layer, which results from an expansion of the hierarchicalconfiguration of the first processing description part in accordancewith data described in the hierarchical configuration description partand the identifier expanding part.
 10. The software generating systemfor an automobile controller according to claim 9, further comprising acompiler for converting the second processing description part into anobject file.
 11. The software generating system for an automobilecontroller according to claim 10, further comprising a linker forgenerating control software to be written in a storage unit of theautomobile controller by linking the object file to an applicationobject file.
 12. The software generating system for an automobilecontroller according to claim 9, wherein the hierarchical configurationdescription part includes the names of output terminals of themicroprocessor.
 13. The software generating system for an automobilecontroller according to claim 9, wherein the identifier expanding partincludes an identifier linking instruction in a programming language.14. The software generating system for an automobile controlleraccording to claim 9, further comprising a hierarchical configurationgenerator for generating the hierarchical configuration description partaccording to an input/output terminal list in which correspondencebetween hardware devices and input/output terminals of a control unitincluding the microprocessor is described.
 15. The software generatingsystem for an automobile controller according to claim 14, wherein thehierarchical configuration generator includes a means for generating thehierarchical configuration description part according to an input/outputterminal list described in specifications for the automobile controller.16. The software generating system for an automobile controlleraccording to claim 9, further comprising a means for generating sourcecode of an application program that is part of software executed in acontrol unit in the automobile controller; a preprocessor for convertingthe source code of the application program into an object file; acompiler for converting the second processing description part resultingfrom the expansion into another object file; a linker for linking theapplication program and the second processing description part, whichhave been converted into the object files; and a means for writingcontrol software resulting from the linking in a storage unit in themicroprocessor
 17. An automobile controller that controls an automobileby using a microprocessor that executes processing according to softwarewritten in a storage unit, wherein the storage unit stores software thatincludes a first processing description part in which layered processingis described, a hierarchical configuration description part in which thehierarchical configuration of the first processing description part isdescribed, an identifier expanding part for expanding an identifier, anda second processing description part comprising a single layer, whichresults from an expansion of the hierarchical configuration of the firstprocessing description part in accordance with data described in thehierarchical configuration description part and the identifier expandingpart.
 18. A storage unit storing software of a microprocessor thatexecutes processing in an automobile controller for controlling anautomobile, the storage unit stores software that includes a firstprocessing description part in which layered processing is described, ahierarchical configuration description part in which the hierarchicalconfiguration of the first processing description part is described, anidentifier expanding part for expanding an identifier, and a secondprocessing description part comprising a single layer, which resultsfrom an expansion of the hierarchical configuration of the firstprocessing description part in accordance with data described in thehierarchical configuration description part and the identifier expandingpart.